http://www.ietf.org/rfc/rfc26 1 7.txt 



Network Working Group 
Request for Comments: 2617 
Obsoletes: 2069 
Category: Standards Track 



J. Franks 
Northwestern University 



P. Hallam-Baker 
Verisign, Inc. 



J. Hostetler 
AbiSource, Inc. 
S . Lawrence 
Agranat Systems, Inc. 

P. Leach 
Microsoft Corporation 
A. Luotonen 

Netscape Communications Corporation 

L. Stewart 
Open Market, Inc. 

June 1999 



HTTP Authentication: Basic and Digest Access Authentication 

Status of this Memo 

This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
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"HTTP/1.0", includes the specification for a Basic Access 
Authentication scheme. This scheme is not considered to be a secure 
method of user authentication (unless used in conjunction with some 
external secure system such as SSL [5]), as the user name and 
password are passed over the network as cleartext. 

This document also provides the specification for HTTP's 
authentication framework, the original Basic authentication scheme 
and a scheme based on cryptographic hashes, referred to as "Digest 
Access Authentication" . It is therefore also intended to serve as a 
replacement for RFC 2069 [6], Some optional elements specified by 
RFC 2069 have been removed from this specification due to problems 
found since its publication; other new elements have been added for 
compatibility, those new elements have been made optional, but are 
strongly recommended. 
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Like Basic, Digest access authentication verifies that both parties 
to a communication know a shared secret (a password) ; unlike Basic, 
this verification can be done without sending the password in the 
clear, which is Basic's biggest weakness. As with most other 
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authentication protocols, the greatest sources of risks are usually 

found not in the core protocol itself but in policies and procedures 
surrounding its use . 
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1 Access Authentication 

1.1 Reliance on the HTTP/1.1 Specification 

This specification is a companion to the HTTP/1.1 specification [2]. 
It uses the augmented BNF section 2.1 of that document, and relies on 
both the non-terminals defined in that document and other aspects of 
the HTTP/1.1 specification. 

1 . 2 Access Authentication Framework 
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HTTP provides a simple challenge-response authentication mechanism 
that MAY be used by a server to challenge a client request and by a 
client to provide authentication information. It uses an extensible, 
case-insensitive token to identify the authentication scheme, 
followed by a comma-separated list of attribute-value pairs which 
carry the parameters necessary for achieving authentication via that 
scheme . 

auth-scheme = token 

auth-param = token " = " ( token | quoted-string ) 

The 401 (Unauthorized) response message is used by an origin server 
to challenge the authorization of a user agent. This response MUST 
include a WWW-Authenticate header field containing at least one 
challenge applicable to the requested resource. The 407 (Proxy 
Authentication Required) response message is used by a proxy to 
challenge the authorization of a client and MUST include a Proxy- 
Authenticate header field containing at least one challenge 
applicable to the proxy for the requested resource. 

challenge = auth-scheme 1*SP l#auth-param 

Note: User agents will need to take special care in parsing the WWW- 
Authenticate or Proxy-Authenticate header field value if it contains 
more than one challenge, or if more than one WWW-Authenticate header 
field is provided, since the contents of a challenge may itself 
contain a comma-separated list of authentication parameters. 

The authentication parameter realm is defined for all authentication 
schemes : 

realm = "realm" "=" realm-value 

realm-value = quoted-string 
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The realm directive (case-insensitive) is required for all 
authentication schemes that issue a challenge. The realm value 
(case-sensitive) , in combination with the canonical root URL (the 
absoluteURI for the server whose abs_path is empty; see section 5.1.2 
of [2]) of the server being accessed, defines the protection space. 
These realms allow the protected resources on a server to be 
partitioned into a set of protection spaces, each with its own 
authentication scheme and/or authorization database. The realm value 
is a string, generally assigned by the origin server, which may have 
additional semantics specific to the authentication scheme. Note that 
there may be multiple challenges with the same auth-scheme but 
different realms. 

A user agent that wishes to authenticate itself with an origin 
server — usually, but not necessarily, after receiving a 401 
(Unauthorized) --MAY do so by including an Authorization header field 
with the request. A client that wishes to authenticate itself with a 
proxy — usually, but not necessarily, after receiving a 407 (Proxy 
Authentication Required) — MAY do so by including a Proxy- 
Authorization header field with the request. Both the Authorization 
field value and the Proxy-Authorization field value consist of 
credentials containing the authentication information of the client 
for the realm of the resource being requested. The user agent MUST 
choose to use one of the challenges with the strongest auth-scheme it 
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understands and request credentials from the user based upon that 
challenge . 

credentials = auth-scheme #auth-param 

Note that many browsers will only recognize Basic and will require 
that it be the first auth-scheme presented. Servers should only 
include Basic if it is minimally acceptable. 

The protection space determines the domain over which credentials can 
be automatically applied. If a prior request has been authorized, the 
same credentials MAY be reused for all other requests within that 
protection space for a period of time determined by the 
authentication scheme, parameters, and/or user preference. Unless 
otherwise defined by the authentication scheme, a single protection 
space cannot extend outside the scope of its server. 

If the origin server does not wish to accept the credentials sent 
with a request, it SHOULD return a 401 (Unauthorized) response. The 
response MUST include a WWW-Authenticate header field containing at 
least one (possibly new) challenge applicable to the requested 
resource. If a proxy does not accept the credentials sent with a 
request, it SHOULD return a 407 (Proxy Authentication Required) .. The 
response MUST include a Proxy-Authenticate header field containing a 
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(possibly new) challenge applicable to the proxy for the requested 
resource . 

The HTTP protocol does not restrict applications to this simple 
challenge-response mechanism for access authentication. Additional 
mechanisms MAY be used, such as encryption at the transport level or 
via message encapsulation, and with additional header fields 
specifying authentication information. However, these additional 
mechanisms are not defined by this specification. 

Proxies MUST be completely transparent regarding user agent 
authentication by origin servers. That is, they must forward the 
WWW-Authenticate and Authorization headers untouched, and follow the 
rules found in section 14.8 of [2]. Both the Proxy-Authenticate and 
the Proxy-Authorization header fields are hop-by-hop headers (see 
section 13.5.1 of [2]) . 

2 Basic Authentication Scheme 

The "basic" authentication scheme is based on the model that the 
client must authenticate itself with a user-ID and a password for 
each realm. The realm value should be considered an opaque string 
which can only be compared for equality with other realms on that 
server. The server will service the request only if it can validate 
the user-ID and password for the protection space of the Request-URI . 
There are no optional authentication parameters. 

For Basic, the framework above is utilized as follows: 

challenge = "Basic" realm 
credentials = "Basic" basic-credentials 

Upon receipt of an unauthorized request for a URI within the 
protection space, the origin server MAY respond with a challenge like 
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the following: 

WWW-Authenticate: Basic realm="WallyWorld" 

where "WallyWorld" is the string assigned by the server to identify 
the protection space of the Request-URI. A proxy may respond with the 
same challenge using the Proxy-Authenticate header field. 

To receive authorization, the client sends the userid and password, 
separated by a single colon (":") character, within a base64 [7] 
encoded string in the credentials. 

basic-credentials = base64-user-pass 

base64-user-pass = <base64 [4] encoding of user-pass, 
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except not limited to 76 char/line> 
user-pass = userid " : " password 
userid = *<TEXT excluding " :"> 

password = *TEXT 

Userids might be case sensitive. 

If the user agent wishes to send the userid "Aladdin" and password 
"open sesame", it would use the following header field: 

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

A client SHOULD assume that all paths at or deeper than the depth of 
the last symbolic element in the path field of the Request-URI also 
are within the protection space specified by the Basic realm value of 
the current challenge. A client MAY preemptively send the 
corresponding Authorization header with requests for resources in 
that space without receipt of another challenge from the server. 
Similarly, when a client sends a request to a proxy, it may reuse a 
userid and password in the Proxy-Authorization header field without 
receiving another challenge from the proxy server. See section 4 for 
security considerations associated with Basic authentication. 

3 Digest Access Authentication Scheme 

3.1 Introduction 

3.1.1 Purpose 

The protocol referred to as "HTTP/1. 0" includes the specification for 
a Basic Access Authentication scheme [1]. That scheme is not 
considered to be a secure method of user authentication, as the user 
name and password are passed over the network in an unencrypted form. 
This section provides the specification for a scheme that does not 
send the password in cleartext, referred to as "Digest Access 
Authentication" . 

The Digest Access Authentication scheme is not intended to be a 
complete answer to the need for security in the World Wide Web. This 
scheme provides no encryption of message content. The intent is 
simply to create an access authentication method that avoids the most 
serious flaws of Basic authentication. 

3.1.2 Overall Operation 
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Like Basic Access Authentication, the Digest scheme is based on a 
simple challenge-response paradigm. The Digest scheme challenges 
using a nonce value. A valid response contains a checksum (by 
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default, the MD5 checksum) of the username, the password, the given 
nonce value, the HTTP method, and the requested URI . In this way, the 
password is never sent in the clear. Just as with the Basic scheme, 
the username and password must be prearranged in some fashion not 
addressed by this document. 

3.1.3 Representation of digest values 

An optional header allows the server to specify the algorithm used to 
create the checksum or digest. By default the MD5 algorithm is used 
and that is the only algorithm described in this document. 

For the purposes of this document, an MD5 digest of 128 bits is 
represented as 32 ASCII printable characters. The bits in the 128 bit 
digest are converted from most significant to least significant bit, 
four bits at a time to their ASCII presentation as follows. Each four 
bits is represented by its familiar hexadecimal notation from the 
characters 0123456789abcdef . That is, binary 0000 gets represented by 
the character ' 0', 0001, by 'l 1 , and so on up to the representation 
of 1111 as 1 f ' . 

3.1.4 Limitations 

The Digest authentication scheme described in this document suffers 
from many known limitations. It is intended as a replacement for 
Basic authentication and nothing more. It is a password-based system 
and (on the server side) suffers from all the same problems of any 
password system. In particular, no provision is made in this protocol 
for the initial secure arrangement between user and server to 
establish the user's password. 

Users and implementors should be aware that this protocol is not as 
secure as Kerberos, and not as secure as any client-side private-key 
scheme. Nevertheless it is better than nothing, better than what is 
commonly used with telnet and ftp, and better than Basic 
authentication . 

3.2 Specification of Digest Headers 

The Digest Access Authentication scheme is conceptually similar to 
the Basic scheme. The formats of the modified WWW-Authenticate header 
line and the Authorization header line are specified below. In 
addition, a new header, Authentication-Info, is specified. 
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3.2.1 The WWW-Authenticate Response Header 

If a server receives a request for an access-protected object, and an 
acceptable Authorization header is not sent, the server responds with 
a "401 Unauthorized" status code, and a WWW-Authenticate header as 
per the framework defined above, which for the digest scheme is 
utilized as follows: 

challenge = "Digest" digest-challenge 

digest-challenge = 1# { realm | [ domain ] | nonce I 

[ opaque ] | [ stale ] | [ algorithm ] | 
[ qop-options ] | [auth-param] ) 



domain 

URI 

nonce 

nonce-value 
opaque 
stale 
algorithm 

qop-options 
qop-value 



"domain" "=" <"> URI { 1*SP URI ) <"> 
absoluteURI | abs path 



nonce 



it M it 



nonce-value 



quoted-string 
"opaque" "=" quoted-string 
"stale" " = " ( "true" I "false" ) 
"algorithm" "=" ( "MD5 " I "MD5-sess" ! 
token ) 

"qop" "=" <"> l#qop-value <"> 
"auth" I "auth-int" i token 



The meanings of the values of the directives used above are as 
follows : 



realm 

A string to be displayed to users so they know which username and 
password to use. This string should contain at least the name of 
the host performing the authentication and might additionally 
indicate the collection of users who might have access. An example 
might be "registered_users@gotham.news.com". 

domain 

A quoted, space-separated list of URIs, as specified in RFC XURI 
[7], that define the protection space. If a URI is an abs_path, it 
is relative to the canonical root URL (see section 1.2 above) of 
the server being accessed. An absoluteURI in this list may refer to 
a different server than the one being accessed. The client can use 
this list to determine the set of URIs for which the same 
authentication information may be sent: any URI that has a URI in 
this list as a prefix (after both have been made absolute) may be 
assumed to be in the same protection space. If this directive is 
omitted or its value is empty, the client should assume that the 
protection space consists of all URIs on the responding server. 
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This directive is not meaningful in Proxy-Authenticate headers, for 
which the protection space is always the entire proxy; if present 
it should be ignored. 

nonce 

A server-specified data string which should be uniquely generated 
each time a 401 response is made. It is recommended that this 
string be base64 or hexadecimal data. Specifically, since the 
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string is passed in the header lines as a quoted string, the 
double-quote character is not allowed. 

The contents of the nonce are implementation dependent. The quality 
of the implementation depends on a good choice. A nonce might, for 
example, be constructed as the base 64 encoding of 

time-stamp H (time-stamp " : " ETag ":" private-key) 

where time-stamp is a server-generated time or other non-repeating 
value, ETag is the value of the HTTP ETag header associated with 
the requested entity, and private-key is data known only to the 
server. With a nonce of this form a server would recalculate the 
hash portion after receiving the client authentication header and 
reject the request if it did not match the nonce from that header 
or if the time-stamp value is not recent enough. In this way the 
server can limit the time of the nonce's validity. The inclusion of 
the ETag prevents a replay request for an updated version of the 
resource. (Note: including the IP address of the client in the 
nonce would appear to offer the server the ability to limit the 
reuse of the nonce to the same client that originally got it. 
However, that would break proxy farms, where requests from a single 
user often go through different proxies in the farm. Also, IP 
address spoofing is not that hard.) 

An implementation might choose not to accept a previously used 
nonce or a previously used digest, in order to protect against a 
replay attack. Or, an implementation might choose to use one-time 
nonces or digests for POST or PUT requests and a time-stamp for GET 
requests. For more details on. the issues involved see section 4. 
of this document. 

The nonce is opaque to the client, 
opaque 

A string' of data, specified by the server, which should be returned 
by the client unchanged in the Authorization header of subsequent 
requests with URIs in the same protection space. It is recommended 
that this string be base64 or hexadecimal data. 
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stale 

A flag, indicating that the previous request from the client was 
rejected because the nonce value was stale. If stale is TRUE 
(case-insensitive) , the client may wish to simply retry the request 
with a new encrypted response, without reprompting the user for a 
new username and password. The server should only set stale to TRUE 
if it receives a request for which the nonce is invalid but with a 
valid digest for that nonce (indicating that the client knows the 
correct username/password) . If stale is FALSE, or anything other 
than TRUE, or the stale directive is not present, the username 
and/or password are invalid, and new values must be obtained. 

algorithm 

A string indicating a pair of algorithms used to produce the digest 
and a checksum. If this is not present it is assumed to be "MD5". 
If the algorithm is not understood, the challenge should be ignored 
(and a different one used, if there is more than one) . 
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In this document the string obtained by applying the digest 
algorithm to the data "data" with secret "secret" will be denoted 
by KD(secret, data), and the string obtained by applying the 
checksum algorithm to the data "data" will be denoted H(data). The 
notation unq(X) means the value of the quoted-string X without the 
surrounding quotes . 

For the "MD5" and "MD5-sess" algorithms 
H(data) = MD5(data) 

and 

KD(secret, data) = H {concat (secret , " : " , data)) 

i.e., the digest is the MD5 of the secret concatenated with a colon 
concatenated with the data. The "MD5-sess" algorithm is intended to 
allow efficient 3rd party authentication servers; for the 
difference in usage, see the description in section 3.2.2.2. 

qop-options 

This directive is optional, but is made so only for backward 
compatibility with RFC 2069 [6]; it SHOULD be used by all 
implementations compliant with this version of the Digest scheme. 
If present, it is a quoted string of one or more tokens indicating 
the "quality of protection" values supported by the server. The 
value "auth" indicates authentication; the value "auth-int" 
indicates authentication with integrity protection; see the 
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descriptions below for calculating the response directive value for 
the application of this choice. Unrecognized options MUST be 
ignored . 

auth-param 

This directive allows for future extensions. Any unrecognized 
directive MUST be ignored. 

3.2.2 The Authorization Request Header 

The client is expected to retry the request, passing an Authorization 
header line, which is defined according to the framework above, 
utilized as follows. 

credentials = "Digest" digest-response 

digest-response = 1# ( username | realm | nonce I digest-uri 
| response | [ algorithm ] I [cnonce] | 
[opaque] 1 [message-qop] | 

[nonce-count] | [auth-param] ) 

username = "username" username-value 

username-value = quoted-string 

digest-uri = "uri" "=" digest-uri-value 

digest-uri-value = request-uri ; As specified by HTTP/1.1 

message-qop = "qop" "=" qop-value 

cnonce = "cnonce" " = " cnonce-value 

cnonce-value = nonce-value 

nonce-count = "nc" "=" nc-value 
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nc-value = 8LHEX 

response = "response" " = " request-digest 

request-digest = <"> 32LHEX <"> 

LHEX = "0" | "1" | "2" | "3" I 

"4" | "5" | "6" | "7 M | 

"8" | "9" | "a" | "b" I 

"c" I "d" I "e" I M f" 

The values of the opaque and algorithm fields must be those supplied 
in the WWW-Authenticate response header for the entity being 
requested. 

response 

A string of 32 hex digits computed as defined below, which proves 
that the user knows a password 

username 

The user's name in the specified realm. 
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digest-uri 

The URI from Request-URI of the Request-Line; duplicated here 
because proxies are allowed to change the Request-Line in transit. 

qop 

Indicates what "quality of protection" the client has applied to 
the message. If present, its value MUST be one of the alternatives 
the server indicated it supports in the WWW-Authenticate header. 
These values affect the computation of the request-digest. Note 
that this is a single token, not a quoted list of alternatives as 
in WWW- Authenticate. This directive is optional in order to 
preserve backward compatibility with .a minimal implementation of 
RFC 2069 [6], but SHOULD be used if the server indicated that qop 
is supported by providing a qop directive in the WWW-Authenticate 
header field. 

cnonce 

This MUST be specified if a qop directive is sent (see above) , and 
MUST NOT be specified if the server did not send a qop directive in 
the WWW-Authenticate header field. The cnonce-value is an opaque 
quoted string value provided by the client and used by both client 
and server to avoid chosen plaintext attacks, to provide mutual 
authentication, and to provide some message integrity protection. 
See the descriptions below of the calculation of the response- 
digest and request-digest values. 

nonce-count 

This MUST be specified if a qop directive is sent (see above), and 
MUST NOT be specified if the server did not send a qop directive in 
the WWW-Authenticate header field. The nc-value is the hexadecimal 
count of the number of requests (including the current request) 
that the client has sent with the nonce value in this request. For 
example, in the first request sent in response to a given nonce 
value, the client sends "nc=00000001" . The purpose of this 
directive is to allow the server to detect request replays by 
maintaining its own copy of this count - if the same nc-value is 
seen twice, then the request is a replay. See the description 
below of the construction of the request-digest value. 
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auth-param 

This directive allows for future extensions. Any unrecognized 
directive MUST be ignored. 

If a directive or its value is improper, or required directives are 
missing, the proper response is 400 Bad Request. If the request- 
digest is invalid, then a login failure should be logged, since 
repeated login failures from a single client may indicate an attacker 
attempting to guess passwords. 
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The definition of request-digest above indicates the encoding for its 
value. The following definitions show how the value is computed. 

3.2.2.1 Request-Digest 

If the "qop" value is "auth" or "auth-int" : 

request-digest = <"> < KD ( H(A1), unq (nonce-value ) 

" : " nc-value 
":" unq (cnonce-value ) 
" : " unq (qop-value ) 
" :" H{A2) 

) <"> 

If the "qop" directive is not present (this construction is for 
compatibility with RFC 2069) : 

request-digest = 

<"> < KD ( H(A1), unq (nonce-value) " : " H(A2) ) > 

<"> 

See below for the definitions for Al and A2 . 

3.2.2.2 Al 

If the "algorithm" directive's value is "MD5" or is unspecified, then 
Al is: 

Al = unq (username-value) ":" unq ( realm-value ) ":" passwd 

where 

passwd = < us 
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[Sip-implementors] RE: www-authenticate 
header 

Jonathan Rosenbergj drosen@ d ynamicsoft.com 
Mon, 4Jun 2001 12:23:41 -0400 

• Previous message: [Si p-implementors] RE: www-authenticate header 

• Next message: [Si p-implementors] (no sub j ect) 

• Messages sorted by: [ date ] [ thread ] [ sub j ect ] [ author ] 



> Original Message 

> From: aki . niemiQnokia . com [mail toi aki . niemiQnokia . com ] 

> Sent: Monday, June 04, 2001 9:02 AM 

> To : jdrosenQdynamicsoft. com 

> Cc: sunilkQnetbrahma . com ; sip~implementors@cs . Columbia . edu 

> Subject: RE: [Sip-implementors] RE: www-authenticate header 
> 

> 

> Hi, 

> 

> A quick question below, . . 
> 

> > > Original Message 

> > > From: T.Sunil Kumar [mail to: sunilk@netbrahma . com ] 

> > > Sent: Thursday, May 17, 2001 9:14 AM 

> > > To: SIP implementors ; Jonathan Rosenberg 

> > > Subject: www-authenticate header 

> > > 

> > > 

> > > Hi, 

> > > 

> > > Should it be treated as 401 response header alone or 

> request header 

> > > also? 

> > 

> > It used to be both request and response , since we used to support 

> > authentication of responses by "mirroring" the request 

> authentication 

> > mechanism . However, rfc2611 supports a mechanism for response 

> > authentication 

> > that is now to be used instead. THerefore , WWW-AUthenticate 

> > should just be a 

> > request header. 

> > 

> > This will be reflected in the next rev. 
> 

> This sounds good. Just for clarification, is this to say that 

> the RFC 2611 

> style authentication-info headers will be added to the next SIP bis? 

Yes. This was too big a change for -03, as I wanted to get that out the door 
finally. It will therefore come in -04. 

-Jonathan R. 
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Abstract 



This document describes Session Initiation Protocol (SIP), an 
application-layer control (signaling) protocol for creating, 
modifying, and terminating sessions with one or more participants. 
These sessions include Internet telephone calls, multimedia 
distribution, and multimedia conferences. 

SIP invitations used to create sessions carry session descriptions 
that allow participants to agree on a set of compatible media types. 
SIP makes use of elements called proxy servers to help route requests 
to the user's current location, authenticate and authorize users for 
services, implement provider call-routing policies, and provide 
features to users. SIP also provides a registration function that 
allows users to upload their current locations for use by proxy 
servers. SIP runs on top of several different transport protocols. 
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request. A mandatory response header field MUST be present in the 
response, and the header field MUST be understood by the UAC 
processing the response. "Not applicable" means that the header 
field MUST NOT be present in a request. If one is placed in a 
request by mistake, it MUST be ignored by the UAS receiving the 
request. Similarly, a header field labeled "not applicable" for a 
response means that the UAS MUST NOT place the header field in the 
response, and the UAC MUST ignore the header field in the response. 

A UA SHOULD ignore extension header parameters that are not 
understood . 

A compact form of some common header field names is also defined for 
use when overall message size is an issue. 

The Contact, From, and To header fields contain a URI . If the URI 
contains a comma, question mark or semicolon, the URI MUST be 
enclosed in angle brackets (< and >) . Any URI parameters are 
contained within these brackets. If the URI is not enclosed in angle 
brackets, any semicolon-delimited parameters are header-parameters, 
not URI parameters . 

20.1 Accept 

The Accept header field follows the syntax defined in [H14.1], The 
semantics are also identical, with the exception that if no Accept 
header field is present, the server SHOULD assume a default value of 
application/ sdp . 

An empty Accept header field means that no formats are acceptable. 



Rosenberg, et . al. Standards Track [Page 161] 

□ 

RFC 3261 SIP: Session Initiation Protocol June 2002 



Example : 



Header field 


where 


proxy ACK 


BYE 


CAN 


INV 


OPT 


REG 


Accept 


R 




o 




o 


m* 


o 


Accept 


2xx 








o 


m* 


o 


Accept 


415 




c 




c 


c 


c 


Accept -Encoding 


R 




o 




o 


o 


o 


Accept -Encoding 


2xx 








o 


m* 


o 


Accept -Encoding 


415 




c 




c 


c 


c 


Accept -Language 


R 




0 




o 


o 


o 


Accept -Language 


2xx 








o 


m* 


o 


Accept -Language 


415 




c 




c 


c 


c 


Alert-Info 


R 


ar 






o 






Alert-Info 


180 


ar 
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This helps prevent disruptions that could result from the use of 
this header field by untrusted elements. 

Example : 

Alert-Info : <http : //www . example . com/ sounds/moo . wav> 
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20.5 Allow 

The Allow header field lists the set of methods supported by the UA 
generating the message. 

All methods, including ACK and CANCEL, understood by the UA MUST be 
included in the list of methods in the Allow header field, when 
present. The absence of an Allow header field MUST NOT be 
interpreted to mean that the UA sending the message supports no 
methods. Rather, it implies that the UA is not providing any 
information on what methods it supports. 

Supplying an Allow header field in responses to methods other than 
OPTIONS reduces the number of messages needed. 

Example: 

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 

20.6 Authentication-Info 

The Authentication-Info header field provides for mutual 
authentication with HTTP Digest. A UAS MAY include this header field 
in a 2xx response to a request that was successfully authenticated 
using digest based on the Authorization header field. 

Syntax and semantics follow those specified in RFC 2617 [17]. 

Example : 

Authentication-Info: nextnonce="47 364c234 32d2el31a5fb210812c M 

20.7 Authorization 

The Authorization header field contains authentication credentials of 
a UA. Section 22.2 overviews the use of the Authorization header 
field, and Section 22.4 describes the syntax and semantics when used 
with HTTP authentication. 

This header field, along with Proxy-Authorization, breaks the general 
rules about multiple header field values. Although not a comma- 
separated list, this header field name may be present multiple times, 
and MUST NOT be combined into a single header line using the usual 
rules described in Section 7.3. 
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...SPECIFICATION Layer (SSL) protocol. It will be appreciated that although 
in this example the SIP request is an INVITE request , the 
authentication scheme described below can also be used for other types 
of SIP requests, such as REGISTER, MESSAGE... 

...SIP client 72 receives the 407 message 96 from the proxy server 74 in 
response to the INVITE message 82, it decides from the Proxy- 
Authenticate header 98 that the proxy server requires authentication of 
the user by means of the Kerberos mechanism. . . 

...long-term key shared with the KDC 100. If the ticket is valid, the user 
7 6 is authenticated , and the SIP proxy server 7 4 forwards the INVITE 
message 110 to the next proxy 120 on the signaling path. If the client 
72 has requested mutual authentication in the Proxy-Authorization 
header 112 of the INVITE message 110, the proxy server 74 will sign 
future packets from the server to the client using a... 

...Information header 124 that contains the credentials of the proxy 74 to 
allow the client 72 to authenticate the proxy. 

Ultimately, the INVITE message 110 reaches the callee, i.e., the 
SIP client 86 of Bob f s computer 88. If the... 

...server 74 wants to challenge the identity of the SIP client (or its 
user) that sent an INVITE message , it sends a 407 message with a 
Proxy- Authenticate header back to the client. The syntax of 
Proxy-Authenticate header in a preferred embodiment requiring the... the 
signaling processing are shown. The SIP proxy server 74 has been 



configured to require that all INVITE requests be authenticated for 
calls made to the Microsoft.com user name space. As a result, the SIP 
proxy server... in additional to the outbound proxy server 74 of the SIP 
client, and both proxies require client authentication before 
forwarding the INVITE message . In this case, the client 72 first goes 
through the same process as described above in connection. . . 

.above, in a preferred embodiment the NTLM security mechanism can be 
optionally used for the client-proxy authentication . In this case, the 
client first sends an INVITE message 220 without authentication 
data, and the proxy returns a 407 message. The Proxy Authenticate header 
of this 407 message 222... data about the proxy. Based on the 
authentication data in the "200 OK" message 232, the client 
authenticates the proxy, and then sends out another INVITE message 
236. Exemplary messages for this process are provided below. 
FIG. 9 shows a scenario of NTLM-based. . . 

.the security association with the proxy. The proxy then returns a "200 
OK" message 24 6 with Proxy Authentication Information. After 
authenticating the proxy, the client sends a second INVITE message 
248 to the proxy. Exemplary messages for this process are provided below. 



In view of the many. . . 



...CLAIMS message. 

17. A method as in claim 16, wherein the first and second request 
messages are SIP INVITE requests . 

18. A method as in claim 16, wherein the authentication data in the 
proxy-authorization header in the second request message include data 
requesting mutual authentication between. . . 
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...SPECIFICATION for an end user under. 

Referring again to Figure 7 (b) , in line 6, after receiving the INVITE 
message , proxy server 710 contacts authentication server 706 
(illustrated in Figure 7 (a)) to authenticate end user device 700 and end 
user device . . . 



3/3, K/3 (Item 1 from file: 34 9) 

DIALOG (R) File 34 9:PCT FULLTEXT 

(c) 2005 WIPO/Univentio. All rts. reserv. 

01037803 **Image available** 

PACKET-BASED CONVERSATIONAL SERVICE FOR A MULTIMEDIA SESSION IN A MOBILE 

COMMUNICATIONS SYSTEM 
SERVICE CONVERSATIONAL FONDE SUR LA COMMUTATION PAR PAQUETS -POUR UNE 

SESSION MULTIMEDIA DANS UN SYSTEME DE COMMUNICATION MOBILE 

Patent Applicant /Assignee : 

TELEFONAKTIEBOLAGET LM ERICSSON ( Publ ) , S-126 25 Stockholm, SE, SE 
(Residence) , SE (Nationality) 
Inventor ( s ) : 

BERGENLID Lars Herbert, Rayvagen 42, S-191 63 Sollentuna, SE, 
OLSSON Magnus, Smab j orksvagen 47, S-163 42 Spanga, SE, 

Legal Representative: 

MONICA MAGNUS SON (agent), Ericsson AB, Patent Unit Radio Networks, S-164 
80 Stockholm, SE, 

Patent and Priority Information (Country, Number, Date) : 

Patent: . WO 200367832 Al 20030814 (WO 0367832) 

Application: WO 2003SE215 20030207 (PCT/WO SE0300215) 

Priority Application: US 2002354483 20020208; US 2003347501 20030121 

Designated States: 

(Protection type is "patent" unless otherwise stated - for applications 
prior to 2004) 

AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ 
EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR 
LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG 
SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW 

(EP) AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI 
SK TR 

(OA) BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG 

(AP) GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW 

(EA) AM AZ BY KG KZ MD RU TJ TM 
Publication Language: English 
Filing Language: English 
Fulltext Word Count: 7316 

Fulltext Availability: 
Detailed Description 

Detailed Description 

. . . session details regarding the number of media flows and requested 
corresponding quality of io service. The IMS authenticates N91 as a 
subscriber and authorizes the session. The SIP INVITE message is 
forwarded to MT2 via external networks. MT2 confirms the session request 
in a SIP "183" Progress... 
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invention, the PBX translator 30 verifies whether the 5 caller is an 
authorized caller by examining the authentication information in the 
body of the INVITE message . Alternatively, the PBX translator 30 does 
not necessarily require authentication for initiating a call through 
the translator. 

If the caller is authenticated or no authentication is necessary. . . 
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Detailed Description 

... The SIP Invite uses the originating wireless endpoint ' s full CDMA 
address for, e.g., authentication. Once authentication is successful, 
the originating EP endpoint reformulates the original SIP Invite 
request to address the destination party directly, but using only the 
SIP URL information corresponding to the originating... 

. . .message contains some CDMA-specific parameters that are not required for 
-SIP VOEP communication, while subsequent to authentication the second 
SEP Invite message contains only parameters that are required for SEP 
VOIP communication and that consequently excludes CDMA-specific 
parameters . . . 
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Detailed Description 

... may be adopted as a control protocol. For 

example, the session invitation message may be a SIP 

INVITE request including an authentication header field. 
The response message may be a SIP response message 
including an authorization header field. 

The ... present embodiment, an additional field, 



i.e., an additional parameter has to be included into the 
SIP INVITE request . Namely, the information needed for 
performing the authentication is included in the SIP 

INVITE request . In particular, the RAND number which is 
provided by an authentication entity (e.g., AuC or a SIP 
server which actually performs the authentication) has to 
be included. .. of request) may include the necessary information, namely 
the RAND., i.e., challenge, and information regarding the 

authentication scheme. 

3S After receiving such a SIP INVITE request , the mobile 
- 10 

node responses with a SIP response like, e.g., 200 OK or 
the like... which is to be used by the SIP 
server . 

5 2) The SIP server forwards the SIP INVITE request 
(containing the authentication extensions with the 
authentication parameters) towards the mobile node (steps 
S4 and S5) . According to the present embodiment, the SIP 
server determines according to network policies that it 
is the authentication verification point. Hence, it 
forwards the SIP INVITE request with the authentication 
extensions containing only AuthDatal and puts its URL in 
the VIA field. 

Any SIP server or proxy... the SIP INVITE request to the mobile node 
unchanged. 

3) The mobile node (MS), receiving the SIP INVITE 
request containing the RAND parameter, executes the 

Z'S authentication algorithm taking AuthDatal as input and 
producing an output value AuthData2 . 

4) When the mobile node answers ... the SIP 

proxy. The SIP server may determine according to network 
policies that it is not the authentication verification 
point. In this case, it forwards the SIP INVITE request 
with the authentication extensions containing AuthDatal 
and AuthResp. 

Any SIP server or proxy receiving authentication 

extension with both RAND and... in this example the SIP server 

determines based on the network policies that it is not 

the authentication verification point, but the SIP proxy. 

Hence, it forwards the INVITE request including AuthDatal 
and AuthResp to the proxy I in step S/la. 

Based on the network policies and on receiving the INVITE 
request includingAuthDatal and AuthResp, the SIP proxy 
determines that it is the authentication verification 
point. Hence, it extracts the AuthResp from the INVITE 

message and stores it. Thereafter, it forwards the INVITE 
request including only AuthDatal in step SS. In addition... 

Claim 

parameter, the user is able to perform 
an authentication of the network. 

Moreover, also a password based authentication scheme 
could be used. In this case, the SIP INVITE message as 
described above, some text requesting the user to type 
his password can be included. That is ... protocol . 
io 

7 The method according to claim 6, wherein the session 
invitation message is a SIP INVITE request including an 
authentication header field. 



8 The method according to claim 6, wherein the 
response message is a SIP response ... protocol 

21 The network system according to claim 20, wherein 

the session invitation message is a SIP INVITE request 
including an authentication header field. 

22 The network system according to claim 20, wherein 

the response message is a SIP.. .35 The network control element according 
to claim 34, 

wherein the session invitation message is a SIP INVITE 

request including an authentication header field. 
5- 36. The network control element according to claim 34, 
wherein the response message is ... protocol . 

49 The subscriber equipment according to claim 48, 
wherein the session invitation message is a SIP INVITE 

request including an authentication header field. 

50 The subscriber equipment according to claim 49, 
wherein the response 
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. . . associate with the session set-up procedures of already 
registered user equipment such as the so called INVITE 
message and so on may also need to be authenticated . The 
authentication of the session set-up request may, however, 



not be required every time but may be accomplished ... subscriber server 
(HSS) may not be 

able to authenticate all session set-up requests. The HSS 

cannot authenticate e.g. all SIP INVITE messages because 

these messages have not necessarily been passed to 1 ...service attacks 

associated with registering messages are quickly noticed. The 

inventors have also found it possible to authenticate set-up 

messages such as the INVITE messages at a separate controller 

entity than where e.g. the registering messages are 

authenticated. The authentication of... needed for authentication purposes 
in the user 1. 

The user equipment 1 checks appropriate parameters, computes 
an authentication response RES and sends the RES in an 
appropriate INVITE message (5.) to the P-CSCF 30. The P-CSCF 
forwards the message (6.) with to the S method may 
also be used for other purposes that for authentication of 
session initiation messages (e.g. the INVITE messages ). The 
method can be used to authenticate whichever messages (e.g. 

any other SIP methods) that bypasses an intermediate 
controller entity such as the... 
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... password entered as DTMF digits. As an alternate to password 

collection through DTMF, SCS 106 may support authentication using SIP. 
In this scenario, the SIP INVITE message carries additional user 



parameters, such as usemame/password combination that may be used by SCS 
106 to. . . 
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... back a SIP acknowledgement message to the proxy in step 505. 
15 

User A subsequently repeats the INVITE request in step 507, but this 
time includes an authentication header in response to the challenge of 
step 503. If the authentication of User A is satisfactory... 
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... back a SIP acknowledgement message to the proxy in step 305. 

[00721 User A subsequently repeats the INVITE request in step 307, 
but this time includes an authentication header in response to the 
challenge of step 303. If the authentication of User A is satisfactory... 
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stack, where the message is received, identified and sent, is modified 
to handle all the security messages. Invite messages and 

authentication related response messages are always sent to security 
manager. In practice, this means that the authentication is... 
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... relating to each of the medias being requested for the session. 
The proxy-CSCF-A forwards the INVITE message to UE-A's serving 
CSCF-A which authenticates UE-A and authorizes the multimedia call. The 

INVITE message is then forwarded to the B side through UE-B f s 
serving-CSCF-B to UE-B... 
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English Abstract 

...an SIP request from the user agent to the server. The server then 
forwards a request for authentication to the user agent in response to 
the invite request , the request for authentication including 
information that the authentication will be performed using a UMTS AKA 
mechanism. The user agent then forwards and authentication response to. . . 

...response to the SIP request. The SIP request may include any 

standardized SIP request including an SIP INVITE request or an SIP 
REGISTER request. The request for authentication may include one of an 
SIP 401 Unauthorized code or an SIP 407 Proxy Authentication Required 
code . . . 



Detailed Description 

MAC (Message Authentication Code) is considered to be invalid) . 

Referring now to Figure 2, which illustrates proxy authentication after 
an INVITE request is presented, upon the UA forwarding an INVITE 
request to the CSCF, the CSCF may ask for an authentication with a 4 07 
Proxy Authentication Required response. The 407 responds contains a 
Proxy-Autbenticate response header field. . . 



. . . parameters . 



After receiving the 407 response, the UA sends an ACK (acknowledgment) 
response and may repeat the INVITE request , the repeated request 
containing the appropriate authentication information in the 
Proxy-Autborization header field. 



4 

In the case of the UMTS AKA procedure, theProxy . 
.challenge) and the AUTN (authentication token). 

After a 401 response, the UE a sends a new REGISTER/ INVITE request 
which 

should contain the appropriate authentication information in the 
Authorization header field: the authentication response (RES) , a 
synchronization failure parameter (AUTS) , or an... 
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. . . support simple call supplementary services like call forwarding, call 
hold and call transfer, conferencing, session change (re- invite , mode 
request ) , security: Authentication , Authorization and privacy, . 
quality of service QOS) signaling, network management and redundancy. 

[77] Now, we will discuss... 
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... voiceinail @sip.wcom 
com> 

Callid: 1234 56@caUing-host . com 
CSeq: I ACK 
Content-Length: 0 

The SIP INVITE request above contains the account information, with 
no 

password authentication . At this point, the IMS 25 prompts the calling 
IMS account user for a password to verify. . . 
. . .CSeq: I ACK 

Content-Length: 0 

In this case, the SIP RMTE request contains no account or authentication 

information, but only the identifier UNKNOWN in the INVITE request 
URL. 

Accordingly, in step 395, a calling party is prompted for a user name and 
password. If . . . 
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